In software development, a framework is generally considered a defined support structure in which other software projects may be organized and developed. A framework may include support programs, code libraries, a scripting language, or other software to help develop and piece together the various components of a software project. By bundling a large amount of reusable code into the framework, developers may save time by inserting reusable solutions into their applications instead of rewriting standard lines of code. An example framework may be or include a Java environment. In the Java framework, a program is partially compiled and the result of this compilation is called “byte code”. Due to the partial compilation, an interpreter such as the Java Runtime Environment (JRE) may be used in order to interpret byte code and execute the program.
Before a Java class is executed, the class is “loaded” into the memory through the use of a “ClassLoader.” The ClassLoader first finds the file containing or referencing the class to be loaded. Upon locating the class, the files are stored in the memory as either separate files or packed in a Java Archive (JAR) file. Normally, the framework will first execute the JAR file, which triggers the particular application in some manner. The ClassLoader may require information as to the plurality of paths to files containing the byte code as well as paths to the framework of the application. The paths may be provided at the start of the process through a variety of methods. For instance, they may be provided in an environmental variable, handled by the framework entry point, or another known method.
The location of a set of JAR files or of separate compiled Java classes may be defined as a “library.” For example, the libraries in a Java environment may be logically separated into three groups: (1) a system library containing java classes of the JRE; (2) a framework library associated with the framework; and (3) an application library associated with the specific application. The framework may handle the list of JAR files itself and implement its own ClassLoader. In other implementations, the JAR files may be handled by the application, by the system, or by an external method or batch file, each providing its own ClassLoader for performing the necessary loading functions.
Generally, most application developers do not have a direct influence on the framework through which the application is developed or deployed. One reason for limiting an application developer's ability to modify a framework is that upgrades to the framework usually cannot be made without effecting enhancements to the applications being developed therewith, including those developed by other developers who rely on the current state of the framework for successful development. As such, application developers may not be provided with permissions to modify the framework library. However, in certain situations, changes to the framework are necessary in order to get the application to run as desired. Using current solutions, allowing changes to the framework by the application developer may cause environment-wide modifications to the framework and all applications relying thereupon. Identifying and notifying the appropriate developers, as well as modifying the framework in a manner such that environment-wide alterations are made, is often a difficult and time-consuming task. Accordingly, current framework modifications can lead to dysfunction and/or regression to the enhancements of the applications created and run within the framework.